Thanks for the reply and explanation! Indeed, there's already a lot of new features, it would be good to make them official.

Can the allowed cars packet also be used to disable all cars for a certain UCID? I would hope so, because it would be a useful functionality for special events etc... The question is what will then LFS do, if no car is available...

Quote from Scawen :

OK, I've done that now and it will be in the next test patch.

This concerned char "1" width, thanks! Indeed, the other things (colors) are of low priority. I also accept that you do not have a good feeling about sending hidden info to clients, so I'll do what I can using the existing packets (well, sending visible info for now). The new packet of allowed cars per connection looks indeed promising. I guess it will be very handy for all the multiclass and cruising servers... Too bad it means more work for me and others. Hehe, well, thats when we require something and then we get it. Thanks again.

Scawen, first, BIG thanks for all the already implemented new features! Marvelous stuff. Here I dare to mention three more things, maybe not exactly InSim matters, but closely related, I hope:

1) One thing that, well, annoys me quite a bit is that the char "1" is narrower than all the other numbers. This is very unusual, because most fonts keep all the numbers of the same width, for easy aligning. Now if there's a LFS button showing fast changing numbers, the numbers tend to jump around instead of keeping their places. Is there please any chance to make the char 1 the same width as the other numbers?

2) LFS clients support at least 2 more colors that cannot be used by InSim apps, dark gray (when someone disconnects), and light red (when someone is banned). Is there any chance to make these colors (plus possible additional ones) available? I think somebody already asked for this, but I'm not sure if there was any answer.

3) Below the race control message area on screen there seems to be a smaller (and not much used) space for additional info. It displays info e.g. at the race start when pit stop is required. Could this line become available for changes/display, probably using some new commands similar to the RCM ones?

Scawen, of course none of the above is anything major, but if they seem reasonable (especially point 1) and correction/addition is possible and simple, maybe they could be part of some patch.

And how about that server to client (and vice versa) hidden communication, is it still considered a security issue or do you plan to add this in the future? Just so that I know which way to go concerning Airio/Aonio information exchange. Thanks again for all the work and answers!

PS: There is also light blue color when someone is connecting and light orange when showing race results...

Last edited by EQ Worry, Sat, 21 May 2011 18:14.

Ah, damn developers. OK, I hope I'll be able to find some time for tests in a few days... Thanks for info!

No, that is not possible. Many people asked already, Scawen said the track is not done there, so it cannot be done.

Yes, all the AS tracks are great, especially when they include new turns. I'm not so sure about FE tracks with the new straight part though, it seems to me a substantial bit of smoothing would be required there. When I have a bit of time I'll try to make PTH for an F2x track including part of the mini-oval and different first/last turn.

In my attempts to support racing on custom layouts, as proposed and discussed in this thread, I recently added F11. It was a challenge, because it has two new turns and one completely new section, not found on any other FE track. All seems to be working fine under Airio 2.5.4, especially F11R is a usable track. On the other hand F11 is really wild in T1, because there are big jumps making the braking very hard or even impossible. While F11 is fun for a while, I doubt it is a track where any serious racing can take place. I feel there are quite a few other tracks that would fall into "race-impossible" category, such as the one above. While it is a pleasure to try to create paths for reasonably looking and behaving layout tracks, there's no point in supporting wild configurations.

Anyone noticed that there are some LFSW messages in Z32 open tracks? It is really strange and confusing, because I make like 10 laps on some layout (say F11) and then suddenly I see "LFSW - this was your first lap...", next lap shows "LFSW - new PB by ...", but /w pb returns something like "LFSW - PBs are not stored for open tracks". What am I missing? Is that a LFSW bug or how/where can it store open track data? Any ideas?

I can see only one explanation: It is somehow (maybe unintentionally) storing lap times for e.g. FE1X+XFG, any layout. Then it reports all lap time improvements, again without distinguishing between layouts. If that's really the case, then I believe the LFSW messages should not be shown at all because they have zero value. Maybe if Scawen or Victor read this, can you please confirm my assumption? (I was already mentioning this in the main Z32 thread, without response.)

Maybe I'm missing something, but the LFSW is behaving strangely on the open tracks, at least in Z32. Sometimes it reports "this was your first lap on this track", though it was about 20th on a custom layout, sometimes it even reports "lap time" improvements, but then /w pb shows that "lap time is not recorded for open tracks"... Quite confusing to me.

Understood now, thank you! Also thanks for some of the InSim changes, the OG_CTRL and OG_SHIFT bits.

Quote from Scawen :

OutGauge : OG_SHIFT and OG_CTRL (keys) bits added to OutGaugePack

Thank you!

Uhm, I'm not sure what these timing options mean. Anyone please point me somewhere where I could learn more? (How to choose timing, what could it be used for...) Thanks!

Aaahh, very nice, thanks! Yes, indeed, even the vote canceling packet worked (works?) only after majority was reached, that means in the 3 seconds after restart/qualify/end countdown actually starts.

Check out the _Config.txt file for info about basic setup...

Quote from Scawen :

This shouldn't be too expensive, if you only do the full "search for node" on each car at the start of the race or when they leave the pits. Then each time you receive an MCI you only have to check each car's position against the direction and position of the next and previous nodes to see if their line has been crossed. All LFS guests and hosts do it with minimal CPU usage.

Indeed, I do it in a similar way, full node search done just once, then expecting the car to be in the same node, or one or two nodes ahead or one or two back. Only if all these fail, full search is done again.

But still, I would see a great advantage in doing all this node checks and position calculations at the server, sending only results to client InSims. If all clients were to do this, they would all have to include the current custom PTH files and all the code of these calculations, which seems an overkill to me.

Also, for users that would just complicate matters, because if new PTH files are available, they'd need to install them. Having a way to send race position PIDs to clients seems to me as a very nice shortcut. Most clients would ignore such data, some may process it in local InSims.

Quote from Scawen :

One thing about LFS is you can just install the software and you can go and join any host you see in your list. It's a pity if you don't get the full experience without installing some extra software. We'll start to lose something if LFS isn't so easy to use and people need to figure out how to install InSim programs and find out how to connect them.

I completely agree, I would never require the use of a certain client InSim, I know it can be too complicated for many to set it all up properly, even though it may take setting up just 2 or 3 parameters.

I remember that "unnamed" matter, people being kicked by Airio just because they had no nickname. I changed this long time ago, so that now unnamed people just cannot join the race (if admins choose so) and they see messages both in chat and using BIG buttons what should they do to rename.

On the other hand, there's the question of "full experience". For example Aonio, the client-side InSim I'm developing, offers a lot of additional data, like position list with live time differences and their tendencies on splits, car types, penalties, pit stops, correct race positions on multiclass servers, live time/speed comparison with a PB lap, min/max speeds in configurable sections, even a not-so-realistic-but-very-useful radar display showing car locations around/behind you, etc.

For me, full experience from LFS includes all such data, with customizable display and positions on screen, local PBs, remaining fuel laps estimate... Receiving additional data processed at the server (Airio) can make some things more precise. E.g. the race positions can be for Aonio users connected to Airio managed server more precise and updated say every second or two, not just at splits. Also, receiving info about the fact that this is a special half-official track (certain open site + specific layout) makes managing local PBs simple. New layouts are loaded at server, new tracks defined in Airio, clients just receive all the updated info.

Ouch, sorry for these lengthy explanations. In short, ability of client InSims to receive additional info from server InSims can have its uses, I think. I do not see security problems (though I may be short-sighted), as there are already ways to send infos both ways, just not invisibly from server to clients. On the other hand I perfectly understand your concerns. Airio is a large system and quite wide-spread now. It manages many servers in ways that maybe were not your intentions. But I would still hope it is overall perceived as a good thing, especially for the demo servers which are extremely hard/impossible to manage using standard LFS options alone.

Quote from PoVo :

How exactly do you get it from the server log? I've tried many times with no success

The condition is the InSim app must be running locally to server, on the same machine. Then you can add a "watch" on the server log changes, being notified about updates of a certain file, the server log. And then you can parse the updates, looking for "Connect" and grabbing the following IP address, assigning it to the new connection. Well, it is complicated, the info is already available, but of course having it as 4 bytes in the new connection packet would be most handy. I use the IP info for DNS lookup of the domain name, often getting the country of origin.

Quote from PoVo :

Would it be possible to add an IP address variable in the IS_NCN packet? Another goodie would be to add "/ban IP" and "/unban IP" commands. (which isn't that important IMO)

In my experience, banning by IP has all the negatives. 1) In many cases it hits completely innocent people that just happen to share a provider. 2) In as many cases it doesn't block the troublemaker, because he's able to use another IP.

So, having IP in NCP packet would be nice (currently I'm grabbing it from the server log file, which is not 100% reliable), but banning by IP is really dangerous.

Quote from Scawen :

Can you tell me what ideas you have for this? I understand it is quite powerful but I have a couple of concerns.

Well, my idea was not to exclude people without a certain client InSim program, rather to supply information to such clients, if they're in use, that extend what LFS itself can provide. Specifically, I'm now working on a support for certain "half-official" layouts on the open tracks, creating PTH files with nodes that allow for path checks and also more precise (continuous) race position reporting. This is all done in an application connected to server (Airio) and I though that the results could be sent to client InSims (Aonio) saying like: It is this special track (A21 instead of AS2X_layout, K32 instead of KY3_layout) and the current positions are these (PID bytes). Finding car nodes and the resulting positions are relatively expensive operations, so sharing the results would be really advantageous. I am not sure if this could be misused, because it is like a message sent to clients (specific or all), just hidden.

Quote from Scawen :

I don't know but it is on my list to look at it. ... I guess that separate OG_CTRL and OG_SHIFT bits would be better than a combined one.

That sounds really great! I hope it is not too complicated.

Quote from Scawen :

... I intend to add InSim packets that can add and remove autocross objects. ... Loaded layout files also uses the multiplayer system so I guess they would appear naturally.

Does it mean that when a layout is loaded, all its objects will be reported? Uhmm, that could be quite a few packets. Supposing there can be 16 objects per packet it may mean 40 packets for extensive layouts... Of course, it would be great to have all this info!

3) Any chance to receive somehow more infos about the currently loaded layout? New race positions while using layouts are great. The open sites with new tracks using layouts are also cool, so layouts are more important now than they used to be, still there is only minimum data reported by LFS about loaded layouts, basically just the number of objects and the layout name. Personally, I'd love to see reported the X/Y positions of the major race elements, specifically split and finish lines. But I realize this cannot be done in a compatible fashion, except by creating a new packet... eh...

Sorry about this additional thing, but it would make checking the correct layout so much easier.

The hardest part in creating the new PTH files is making new turns, new parts of tracks that cannot be copied from existing tracks. This supposed A16 is just a combination of A11 and A12, which are already done. So preparing PTH for A16 would take about 15 minutes... Tracks currently done: A11, A12, A13, A21, A22, A23, K31, K32, B11, B23, plus all their reversed variants.

EDIT: Currently I'm adding the track recognition / patch checking functionality only to Airio, version 2.5.4. If this all proves to be a workable concept, I'd like to create a separate application, an intermediate layer between LFS server and other InSim applications. But if some of you guys can do the programming, I'd gladly share what I already have concerning PTH processing and node calculation.

Last edited by EQ Worry, Tue, 3 May 2011 16:55.

Nice track, is it part of the "official" layouts? There seem to be some confusion as to what is this track name. I cannot find it in track pictures, I think it should be something like AS16 (A16), a combination of A11 and A12...

The InSim changes so far are great. Thanks! I do not have enough data to be sure every new thing works perfectly, but I believe it is OK. I wonder if two more InSim updates can make it into the official patch:

1) Would it be possible to have communication from server InSim to client(s) InSim? Currently, client InSim apps can send info to server InSim app using the /i command. Not ideal, but it works. But as far as I know, server InSim cannot communicate with client InSims. The idea would be to create a new packet type, just for inter-InSim communication, best working both ways, from client to server, and also from server to client, either a specific one (via ConnID), or to all clients. Alternatively, maybe the existing IS_MTC packet could be used, but when the text starts with a special char, it is not displayed on client(s), it can only be captured by client InSim tools.

2) I was mentioning this before already, but I'll try once more, sorry. A bit somewhere in OutGauge, indicating pressed Ctrl+Shift (on clients) would be nice to have for the option to create multi-purpose buttons (showing alternately e.g. nickname/username). Is it too hard/impossible to add this info to OutGauge? Inside the OutGauge packet OG_x seems to be very empty and there's a spare bit also in DL_x. Please, Scawen, I would really appreciate just a short comment on this addition, like will do / maybe / too complicated / useless / not a priority. Thanks.

Yes, I think maybe this happens when no server is actually connected? I'll take a look at it, but overall it is not so much important, probably just some info in !ver will not be updated/available. But certainly it needs correction, thanks!